IP Multimedia (IPMM) services provide a dynamic combination of voice, video, messaging, data, etc, within the same session. By growing the numbers of basic applications and the media which it is possible to combine, the number of services offered to the end users will grow, and the inter-personal communication experience will be enriched. This will lead to a new generation of personalised, rich multimedia communication services, including so-called “combinational IP Multimedia” services.
IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over mobile communication networks. IMS provides key features to enrich the end-user person-to-person communication experience through the integration and interaction of services. IMS allows new rich person-to-person (client-to-client) as well as person-to-content (client-to-server) communications over an IP-based network. The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or user terminals and application servers). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly. Other protocols are used for media transmission and control, such as Real-time Transport Protocol and Real-time Transport Control Protocol (RTP/RTCP),
Existing cellular network deployments are dominated by the 2G and 3G standards. The process of rolling out so-called 4G networks has just begun, and it will be many years before 4G network coverage is sufficient to allow 2G and 3G networks to be withdrawn completely. A fundamental requirement for real-time service provision is the seamless handover of services for subscribers roaming across cell boundaries of the radio access network (RAN). Given the ongoing co-existence of 2G, 3G and 4G networks, it is particularly desirable to allow for the handover of real-time service connections such as voice calls between the different radio access technologies.
Considering further the 4G technology, this is being specified under the name LTE (Long Term Evolution) and SAE (System Architecture Evolution) in 3GPP. The LTE radio access network technology implements only a packet switched access, in contrast to 2G and 3G (using GERAN and UTRAN radio access network technologies respectively) which provide for both packet switched and circuit switched access. In 2G and 3G networks, packet switched connections are used to carry data whilst circuit switched connections are used for real-time services such as voice calls. In 4G networks, all services will be carried via packet switched connections. In the case of a voice call initiated when a user is attached to a LTE radio access network (termed Evolved UTRAN or E-UTRAN), that call will make use of a packet switched connection. If it is necessary for the call to be transferred to a 2G or 3G radio access network, e.g. because the user roams out of the coverage area of the E-UTRAN and into that of a GERAN or UTRAN network, the call must be switched from a packet switched (PS) access to a circuit switched (CS) access (i.e. an Access Transfer is required). Of course, the process for implementing the handover must be seamless such that little or no disruption of the call is perceived by the user. An appropriate access handover mechanism is also required in the case of the handover of a call from a PS access using a 3G UTRAN (HSPA) access network to a CS call using either 3G UTRAN access or 2G GSM access.
Interworking solutions for IMS Centralized Services (ICS) as specified in 3GPP TS 23.292, “IP Multimedia Subsystem (IMS) centralized services; Stage 2”, allows IMS sessions using CS bearers to be treated as standard IMS sessions, which is required for the purpose of IMS Service Continuity. ICS defines signalling mechanisms between the UE and IMS for transport of information to centralise the service in the IMS, and TS 23.237 “IP Multimedia Subsystem (IMS) Service Continuity” defines the additional procedures needed for service continuity when using CS access for media transport. Within the context of TS 23.292 and TS 23.237, the further 3GPP document TS 23.216: “Single Radio Voice Call Continuity (SRVCC); Stage 2”, describes a mechanism for handing over a voice call from a PS to a CS access.
FIG. 1 illustrates schematically an example of the Single Radio Voice Call Continuity (SRVCC) architecture for providing Access Transfer of a voice call from a PS to a CS access. In this example, a user terminal (or User Equipment, UE, according to 3G terminology) has initiated a voice call using a LTE radio access network (i.e. PS access) which is subsequently to be handed over to either a Universal Terrestrial Radio Access Network (UTRAN) or a GSM/Edge Radio Access Network (GERAN) (i.e. CS access). The call is established using the IMS network described above and which provides a common service control network for the PS and CS domains provided through the LTE, UTRAN, or GERAN radio accesses. In order to implement the Access Transfer, media control must be transferred from the Evolved Packet Core (EPC) network of the 4G domain to an allocated Mobile Switching Centre (MSC) Server within the 2G/3G domain. Other components illustrated in FIG. 1 include a Serving/PDN gateway (S/PDN-GW), a Mobility Management Entity (MME) (both the S/PDN-GW and the MME reside within the EPC), and a Home Subscriber Server that resides within a subscriber's home network.
With reference to FIG. 1, IMS Service Continuity requires a Service Centralization and Continuity (SCC) Application Server (AS) (shown as co-located with an MMTel AS in FIG. 1), and a UE with SC capabilities. In addition, an Access Transfer Control Function (ATCF) and an Access Transfer Gateway (ATGW) may also be used in the serving network (visited if roaming), with the ATCF/ATGW providing additional IMS Service Continuity functions. In this regard, delegating part of the Access Transfer functionality to an ATCF provides advantages related to voice interruption during session handover etc, as the ACTF is located in the same network as the user. In particular, according to 3GPP TS23.237, it is recommended that the ATCF be co-located with one of the existing functional entities within the serving network (e.g. P-CSCF, IBCF, or MSC Server). When SRVCC enhanced with ATCF is used, the ATCF is included in the session control plane for the duration of the call both before and after Access Transfer. The ATGW is controlled by the ATCF and stays in the session media path for the duration of the call and after Access Transfer. The ATGW supports transcoding after SRVCC handover in case the media that was used prior to the handover is not supported by the MSC server.
3GPP TS23.237 and 3GPP TS24.237 define a number of features that may be required in order to support IMS Service Continuity. For example, these features may include but are not limited to the MSC server assisted mid-call feature, SRVCC for calls in alerting state (also known as SRVCC for calls in alerting phase or access transfer for calls in alerting phase), SRVCC for video calls, and multimedia priority services for SRVCC. As such, during the establishment of a session, the SCC AS will indicate to a UE if any of these features are to be applied in any subsequent access transfer that may occur (see 3GPP TS24.237 section 7.3.2 and 8.3.2), However, the SCC AS will only indicate that a feature is to be applied if that feature is supported by the UE, the SCC AS and the MSC servers in the network where the UE is registered and which can be involved in the SRVCC procedures.
In order to indicate their support for any IMS Service Continuity features, a functional entity is required to include the corresponding media feature-tag in a SIP request or a SIP response (see 3GPP TS 24.237 Annex C). However, the SCC AS only interacts with the MSC servers in the network where the UE is registered when access transfer has been initiated. The SCC AS is therefore required to know whether the MSC servers within the serving network support any of these IMS Service Continuity features before it has received any indication from the MSC servers. As such, in order to meet the 3GPP Release 9 and Release 10 standards, it would be necessary to pre-configure the SCC AS with a database indicating whether the MSC servers within a serving network (e.g. V-PLMN) support any of these features. The SCC AS is therefore required to store this information for all of the visited networks into which a UE could roam (e.g. for all V-PLMNs with which the H-PLMN has a roaming agreement). However, maintaining such a database within each SCC AS can be problematic. It would therefore be advantageous if the SCC AS could be aware of the serving networks support for any IMS Service Continuity features without the need for this information to be provided by a pre-configured database.